home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-caradec-mpx-option-00.txt < prev    next >
Text File  |  1993-07-07  |  20KB  |  582 lines
  1.  
  2.  
  3. INTERNET DRAFT                             Jean-Philippe Caradec, Author 
  4.                             Marjo F. Mercado, Editor
  5.                                                  Hewlett-Packard Company
  6.                                                                July 1993
  7.  
  8.                            TELNET MPX option
  9.  
  10.      Status of this Memo
  11.  
  12.      This document is an Internet Draft.  Internet Drafts are
  13.      working documents of the Internet Engineering Task Force
  14.      (IETF), its Areas, and its Working Groups.  Note that other
  15.      groups may also distribute working documents as Internet
  16.      Drafts.
  17.  
  18.      Internet Drafts are draft documents valid for a maximum of six
  19.      months.  Internet Drafts may be updated, replaced, or obsoleted
  20.      by other documents at any time.  It is not appropriate to use
  21.      Internet Drafts as reference material or to cite them other
  22.      than as a ``working draft'' or ``work in progress.''
  23.      Please check the 1id-abstracts.txt listing contained in the
  24.      internet-drafts Shadow Directories on nic.ddn.mil,
  25.      nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au
  26.      to learn the current status of any Internet Draft.
  27.  
  28.      Abstract
  29.  
  30.      This Internet Draft specifies a multiplexing protocol for TELNET
  31.      hosts and devices using the Internet TCP/IP protocol stack. Hosts
  32.      that exchange TELNET Multiplexing (MPX) information within the
  33.      TELNET protocol are expected to adopt and implement this
  34.      protocol.
  35.  
  36.      By negotiating the MPX option, both client and server agree to
  37.      use the specified multiplexing protocol. This negotiation is on a
  38.      per transport link basis. The goal of this option is to use a
  39.      single TCP connection to link device servers and remote hosts.
  40.      This link is then used to carry out multiple session traffic.  
  41.  
  42.      The MPX protocol will be responsible for establishing sessions
  43.      between TELNET client ports and TELNET server hosts. The protocol
  44.      will also be responsible for doing session flow control. To
  45.      handle these two functions, a  header will be added to the TELNET
  46.      data path specifying the session, the data-length, the flow
  47.      control process and the session packet type.  
  48.  
  49.      Document expiration date
  50.  
  51.      The expiration date for this Internet Draft is December 31, 1993.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.                                   1
  60.  
  61.    1.  Command Name and Code
  62.  
  63.        MPX    XX
  64.  
  65.    2.  Command meanings
  66.  
  67.        IAC WILL MPX
  68.  
  69.        Sender is willing to send TELNET data using the session
  70.        multiplexing process on the TCP connection. 
  71.  
  72.        IAC WON'T MPX
  73.  
  74.        Sender refuses to use the session multiplexing process.
  75.  
  76.        IAC DO MPX
  77.  
  78.        Sender is willing to receive TELNET data using the session
  79.        multiplexing process on the TCP connection. 
  80.  
  81.        IAC DON'T MPX
  82.  
  83.        Sender refuses to receive TELNET data with session multiplexing
  84.        encapsulation. 
  85.  
  86.    3.  Default
  87.  
  88.        WON'T MPX
  89.  
  90.        The session multiplexing encapsulation is not used to send
  91.        TELNET data. 
  92.  
  93.        DON'T MPX
  94.  
  95.        The session multiplexing encapsulation is not used to receive
  96.        TELNET data. 
  97.  
  98.    4.  Motivation for the option.
  99.  
  100.        On most of the UNIX (R) machines implementing the ARPA
  101.        protocol stack, the application traffic is character mode
  102.        oriented. This implies a large number of packets containing a
  103.        limited number of characters to handle either on client and
  104.        server side. TELNET clients are supporting more and more
  105.        sessions to a single TELNET server. Moreover, TELNET traffic
  106.        can use an asynchronous link as a physical link with limited
  107.        bandwidth, i.e. SLIP or PPP. 
  108.  
  109.        To avoid an escalation in terms of performance requirements
  110.        either on the client or the server side, the session
  111.        multiplexing TELNET option has been defined to limit the amount
  112.        of exchanged packets using a single TCP connection to carry out
  113.        multiple session traffic. 
  114.  
  115.  
  116.  
  117.                                   2
  118.  
  119.    5.  Description of the TELNET option.
  120.  
  121.        By negotiating the MPX option, both client and server agree to 
  122.        use the specified multiplexing protocol. This negotiation is on
  123.        a per transport link basis. The goal of this option is to use a
  124.        single TCP connection to link device servers and remote hosts.
  125.        This link is then used to carry out multiple session traffic.   
  126.  
  127.        The MPX protocol will be responsible for establishing sessions
  128.        between TELNET client ports and TELNET server hosts. The protocol
  129.        will also be responsible for doing session flow control. To
  130.        handle these two functions, a  header will be added to the
  131.        TELNET data path specifying the session, the data-length, the
  132.        flow control process and the session packet type. 
  133.  
  134.    5.1  MPX header format
  135.   
  136.                     | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0  | 
  137.                     +++++++++++++++++++++++++++++++++
  138.                     +pkt type   | credit    |High L.|     
  139.                     +++++++++++++++++++++++++++++++++
  140.                     +     Low data length           +
  141.                     +++++++++++++++++++++++++++++++++
  142.                     +      local session number     +
  143.                     +++++++++++++++++++++++++++++++++
  144.                     +    reserved for future usage  +
  145.                     +++++++++++++++++++++++++++++++++ 
  146.  
  147.      WHERE:
  148.          
  149.       --> The packet type can take the following values:
  150.  
  151.                0 : TELNET data end session packet.
  152.                1 : TELNET data continue session packet.
  153.                2 : TELNET non-flow controlled data end session packet.
  154.                3 : start request session packet.
  155.                4 : start confirm session packet.
  156.                5 : close session packet.
  157.                6 : echo request/reply session packet.
  158.  
  159.       --> the credit can take values from 0 to 7.
  160.  
  161.       --> the (High L./Low) data length can take values from 0 to 1023.
  162.  
  163.       --> the session number can take values from 0 to 255.
  164.  
  165.       --> The reserved byte must be set to zero.
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.                                    3
  176.  
  177.    5.2  Session number
  178.  
  179.         The session number identifies the session on both sides.
  180.         Both sides of the connection should have the same session
  181.         number. During the start session process, this field is
  182.         filled in by the caller. The session number is linked to a
  183.         dedicated TCP connection to a remote host.
  184.  
  185.         To avoid collision on the allocated session number, the
  186.         TELNET client will use the first available session number
  187.         starting from 0 going to 255 whereas the TELNET server will
  188.         use the first available session number starting from 255
  189.         going to 0. If a start session collision occurs   
  190.         on the same session number, the TELNET client will refuse
  191.         the TELNET server session open whereas the TELNET server has
  192.         to accept the start session from the TELNET client. This
  193.         gives priority to the client start session over the server
  194.         start session.  
  195.  
  196.    5.3  Data length field
  197.  
  198.         The data length specifies the user data size that can be 
  199.         found after the protocol header for that specific session
  200.         packet. If larger packets have to be sent, the "data
  201.         continue/data end" mechanism can be used to reassemble the
  202.         large packet. This data length does not include the MPX
  203.         header size. 
  204.           
  205.    5.4  Credit field
  206.  
  207.         The credit field can take values from 0 to 7.
  208.  
  209.         At session opening, both entities advertise the amount of
  210.         data (the absolute credit) they can receive. The absolute
  211.         credit is defined in units. A unit can be a session data
  212.         packet or a subset of a session data packet if the session
  213.         data packet size is larger than the unit size.
  214.  
  215.         Suppose that the unit size is equal to 10 bytes, a session
  216.         data packet of one byte represents one unit but a session
  217.         data packet of 40 bytes represents 4 units. The absolute
  218.         credit represents the number of units that the entity can
  219.         receive. 
  220.  
  221.         The absolute credit is defined in the start packets. The
  222.         following credits proposed in the credit field represents an 
  223.         incremental number of units.
  224.  
  225.         Credit increment can be delayed to avoid sending data packet
  226.         with length equal to 0 just to increment credit. A credit
  227.         increment timer can be started to favor piggy-backing of
  228.         credit incremental information with data packet to send. 
  229.  
  230.  
  231.  
  232.  
  233.                                   4
  234.  
  235.    5.5  Packet type field.
  236.        
  237.    5.5.1  TELNET data end session packet.
  238.  
  239.           This packet type will contain TELNET data including either
  240.           user data or TELNET command. All the TELNET commands are 
  241.           supported over this mechanism. The credit increment packets
  242.           have to be sent using a data end packet with data-length
  243.           equal to zero.
  244.  
  245.    5.5.2  TELNET data continue session packet
  246.         
  247.           This packet type will contain TELNET data including either
  248.           user data or TELNET command. The "data continue" packet type
  249.           is used when the notion of "fragment" sent over session
  250.           packet is required to reassemble large reads or writes on
  251.           the remote site. In that case, multiple data continue
  252.           packets can be sent followed by a data end packet. 
  253.  
  254.    5.5.3  Start session packet.
  255.  
  256.           The start session packet is used to establish a session 
  257.           over the transport link. The start session packet contains
  258.           the absolute credit value, unit size and information linked
  259.           to the caller identification. 
  260.        
  261.       The start session can be accepted or refused by the called 
  262.       entity.  
  263.  
  264.                     | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0  | 
  265.                     +++++++++++++++++++++++++++++++++
  266.                     +pkt type   | credit    |High L.|     
  267.                     +++++++++++++++++++++++++++++++++
  268.                     +     Low data length           +
  269.                     +++++++++++++++++++++++++++++++++
  270.                     +      local session number     +
  271.                     +++++++++++++++++++++++++++++++++
  272.                     +    reserved for future usage  +
  273.                     +++++++++++++++++++++++++++++++++ 
  274.                     +      MPX data length          +
  275.                     +++++++++++++++++++++++++++++++++
  276.                     +   Credit unit size (higher b.)+
  277.                     +++++++++++++++++++++++++++++++++ 
  278.                     +   Credit unit size (low  b.)  +
  279.                     +++++++++++++++++++++++++++++++++ 
  280.                     +     2 bytes reserved          +
  281.                     +++++++++++++++++++++++++++++++++ 
  282.                     +    upper layer data lgth (h)  +
  283.                     +++++++++++++++++++++++++++++++++ 
  284.                     +    upper layer data lgth (l)  +
  285.                     +++++++++++++++++++++++++++++++++ 
  286.                     +       Upperlayer info         +
  287.                     +++++++++++++++++++++++++++++++++ 
  288.  
  289.  
  290.  
  291.                                   5
  292.  
  293.         The MPX data length represents the data length of the MPX
  294.         parameters in the start session packet. Currently, that length
  295.         is set to 4 (credit parameter + 2 bytes reserved).
  296.  
  297.         The upper layer information follows the MPX parameter fields.
  298.         The upper layer data length field has to be calculated by
  299.         adding the fixed header size plus one byte for the MPX data
  300.         length field plus the MPX data length itself. 
  301.          
  302.    5.5.4  Start confirm session packet.
  303.  
  304.           The start confirm session packet is sent by the called
  305.           TELNET device to accept the session opening. No session data
  306.           must be sent between the start session and the start
  307.           confirm. 
  308.           
  309.  
  310.                     | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0  | 
  311.                     +++++++++++++++++++++++++++++++++
  312.                     +pkt type   | credit    |High L.|     
  313.                     +++++++++++++++++++++++++++++++++
  314.                     +     Low data length           +
  315.                     +++++++++++++++++++++++++++++++++
  316.                     +      local session number     +
  317.                     +++++++++++++++++++++++++++++++++
  318.                     +    reserved for future usage  +
  319.                     +++++++++++++++++++++++++++++++++ 
  320.                     +      MPX data length          +
  321.                     +++++++++++++++++++++++++++++++++
  322.                     +   Credit unit size (higher b.)+
  323.                     +++++++++++++++++++++++++++++++++ 
  324.                     +   Credit unit size (low  b.)  +
  325.                     +++++++++++++++++++++++++++++++++ 
  326.                     +     2 bytes reserved          +
  327.                     +++++++++++++++++++++++++++++++++ 
  328.                     +      local session number     +
  329.                     +++++++++++++++++++++++++++++++++
  330.                     +    upper layer data lgth (h)  +
  331.                     +++++++++++++++++++++++++++++++++ 
  332.                     +    upper layer data lgth (l)  +
  333.                     +++++++++++++++++++++++++++++++++ 
  334.                     +       Upperlayer info         +
  335.                     +++++++++++++++++++++++++++++++++ 
  336.                     
  337.          The same convention as start session packet is used for start
  338.          confirm packet fields.
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.                                    6
  350.  
  351.    5.5.5  Close session packet.
  352.  
  353.           The close session packet is sent for two reasons. The called
  354.           entity specifies that the session is refused or the session
  355.           is ended by one of the entities.
  356.  
  357.  
  358.                     | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0  | 
  359.                     +++++++++++++++++++++++++++++++++
  360.                     +pkt type   | credit    |High L.|     
  361.                     +++++++++++++++++++++++++++++++++
  362.                     +     Low data length           +
  363.                     +++++++++++++++++++++++++++++++++
  364.                     +      local session number     +
  365.                     +++++++++++++++++++++++++++++++++
  366.                     +    reserved for future usage  +
  367.                     +++++++++++++++++++++++++++++++++ 
  368.                     +      MPX data length          +
  369.                     +++++++++++++++++++++++++++++++++
  370.                     +      MPX close reason         +
  371.                     +++++++++++++++++++++++++++++++++
  372.  
  373.  
  374.           When all sessions are closed on a TCP link, the link must
  375.           be disconnected. The MPX data length value is currently one
  376.           because the only MPX field is the close reason.
  377.  
  378.           The close reason can take multiple values:
  379.           
  380.                         1    : session closed by user.
  381.                         2    : session closed on modem down.
  382.                         3    : session closed on reset.
  383.                         4    : session closed by upper layer.
  384.                         5    : session closed by TELNET server.
  385.                         
  386.    5.5.6  Non-flow controlled data session packet.
  387.        
  388.           The non-flow controlled data packet is used to bypass normal
  389.           data path for urgent delivery. There is no non-flow
  390.           controlled data continue session packet. 
  391.        
  392.    5.5.7  Echo request/reply.
  393.        
  394.           The echo request/reply packet is used to determine the
  395.           network delay between the TELNET client and the TELNET
  396.           server. After the link is established, an echo packet is
  397.           sent requesting from the server an immediate reply. The time
  398.           measurement between the request and the reply is then
  399.           computed to optimize the multiplexing timer (see next
  400.           sections). 
  401.  
  402.           The data length is null and the echo request/reply packet is
  403.           not subject to flow-control (no credit unit is consumed to
  404.           send the echo request/reply session packet).
  405.  
  406.  
  407.                                    7
  408.  
  409.    5.6  Multiplexing session over a transport connection.
  410.  
  411.         The multiplexing algorithm is based on a multiplexing timer
  412.         which concatenates the traffic of multiple TELNET sessions.
  413.         The multiplexing timer can take values from 10 to 120 ms.
  414.         The recommended value on client side is 80 ms and on server
  415.         side 10/20 ms. These values are appropriate for interactive
  416.         traffic. 
  417.  
  418.         When the multiplexing timer pops, TELNET data is collected
  419.         from multiple sessions. Before each session user data, the 4
  420.         byte protocol header is added. The data length field of each
  421.         session data permits the demultiplexing process to occur.
  422.  
  423.    6.  Implementation issues.
  424.          
  425.        The MPX protocol implies an encapsulation of the user data
  426.        within a session packet. This new mode is enabled once 
  427.        the TELNET MPX option is negotiated between the two
  428.        entities. 
  429.  
  430.        To avoid mixing TELNET packets with and without headers, we
  431.        expect that any TELNET device implementing MPX option will 
  432.        start its TELNET negotiation with the MPX option negotiation.
  433.        Further TELNET negotiation occurs once the session is
  434.        established.
  435.  
  436.        The multiplexing timer value needs to be dynamically adapted
  437.        to any echo delay modification to favor echo response time.
  438.        The echo request packet should be sent every 10 seconds to
  439.        test response time depending on IP network routes. If
  440.        traffic is rerouted because of router failure, the timer
  441.        should be automatically updated to offer the best echo
  442.        delay/performance compromise.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.                                    8
  466.                       
  467.    7.  Example
  468.  
  469.            users            client                            server
  470.  
  471.  
  472.            user1 "connect"   ------ TCP SYN ------------->
  473.                              <--    TCP SYN/ACK  ---------
  474.                              -------TCP ACK      -------->
  475.  
  476.                             <--  IAC WILL/DO MPX ____________  
  477.                              --  IAC WILL/DO MPX ____________>
  478.                              
  479.                              ------- start session         -->
  480.                              <-------start confirm ----------- 
  481.                              <------ [ TELNET neg ] ----------
  482.                              
  483.                              ------- [ TELNET neg  ] --------->
  484.  
  485.  
  486.            user2 "connect"
  487.                              ------- start session  --------->
  488.                              <-------start confirm ----------- 
  489.                              <------ [ TELNET neg ] ----------
  490.                              
  491.                              ------- [ TELNET neg  ] --------->
  492.  
  493.  
  494.            user1 data  |
  495.                        |
  496.            user2 data  |->  -----<header1>data1<header2>data2 -->
  497.  
  498.  
  499.    8.  Reference
  500.  
  501.        [1] Postel, J., and J. Reynolds, "TELNET PROTOCOL
  502.            SPECIFICATION", RFC 854, USC Information Science
  503.            Institute, May 1983  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.                                    9
  524.  
  525.  
  526.    9. Author's Address
  527.  
  528.       Jean-Philippe Caradec
  529.       Grenoble Networks Division
  530.       Hewlett Packard France
  531.       5, Rue Raymond Chanas
  532.       38320 Eybens 
  533.       France
  534.  
  535.       Phone:  +33 76625518
  536.  
  537.       Email:  caradec@gnlab030.grenoble.hp.com
  538.  
  539.       Marjo F. Mercado
  540.       Grenoble Networks Division - Cupertino
  541.       Hewlett Packard Company
  542.       19420 Homestead Road, MS 43 LH
  543.       Cupertino, CA 95014
  544.       U.S.A.
  545.  
  546.       Phone:  (408) 447-2826
  547.  
  548.       Email:  marjo@cup.hp.com
  549.     
  550.      Document expiration date
  551.  
  552.      The expiration date for this Internet Draft is December 31, 1993.
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.                                    10
  582.